Devices require support for storing sensitive data in databases (DBs) in order to meet higher security requirements. By definition, sensitive data is data that is available for usage in a state where the database user has furnished the master key to the database engine. In order to enable sensitive data in the database, applications require databases to support column wise encryption and databases require applications to configure the sensitive columns of the managed tables. Applications that gain higher security, shall also benefit from seamless co-existence of sensitive and non-sensitive data in the database without compromising on the original capability of the database engine.
Databases are prone to software upgrades for different sensitive column encoders during a device lifecycle requiring the accessing device to also be updated. Porting encrypted data from one encoder to a different encoder has heretofore been a cumbersome process of decrypting the entire database using a first encoder, re-encrypting the database with a second encoder, and writing the re-encrypted data.
A typical DB engine uses a lighter structured query language (SQL) Engine, for example, SQLite.
An SQL Engine is built using different layers. SQLite has 4 main layers:                SQL Statement Processing Layer (SQLite application program interface (API) Layer).        Byte Code Processing Layer (virtual data base engine (VDBE) Layer).        Record Processing Layer (balanced tree (BTree) Layer).        Page Processing Layer (Pager Layer).        
The SQLite API understands the SQL statement and converts the information into SQLite's operational codes. VDBE uses the operational codes to fetch required data from the Btree layer and processes the data and returns the results to the higher layers. The Btree Layer understands the table structure and deals at the level of records. The Pager fetches pages from the DB file, caches, and shares that to the higher layers.
Current mobile terminals use SQLite predominantly to fulfil the need for a SQL DB Engine due to its lighter weight. SQLite currently supports only database file wide confidentiality and integrity.
There is thus a need for Mobile Devices to support storing sensitive data in the database to meet higher security requirements. These Enterprise Applications demand the co-existence of sensitive and non-sensitive data within the same Database. There is further a need to support the co-existence of sensitive and non-sensitive data not only within the same database, but even within a single table, so that the whole Database design then may avoid being unnecessarily complicated by requirements to move sensitive data to different databases. There is a need for a database in which two related sensitive and non-sensitive data that should belong to the same table remain together in the same manner, thus enabling seamless search and other indexing operations.
Further, since migration of the database whenever there is a platform upgrade is costly and greatly affects the user experience, there is a need for a new technique for data to work seamlessly irrespective of upgrade. The new technique should be equipped to plug and play different DB cell encoders/decoders, based on the encoding type of the data.
Accordingly, the present disclosure is provided to address these needs.
The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure.